Medical network

ABSTRACT

Methods for sharing medical costs between prospective patients seeking treatment, and existing patients of a medical network. Prospective patients may actively query medical costs for specific conditions and treatments for the specific conditions previously experienced by existing patients. Existing patients contributing to the documents accessible by the medical network may upload anonymous versions of EOBs, medical bills and medical documents to the medical network in exchange for rewards. The prospective patients may communicate and query the desired information using natural language inputs to instruct a client computing system to search the medical network for relevant treatment information. The prospective patient may use natural language commands or other inputs to filter the query results by condition, location, cost, quality of service, service provider, insurance provider, or any other parameter that may be detailed by the medical documents accessible through the medical network.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application claiming priority to Ser.No. 15/599,028 filed May 18, 2017 the contents of which are herebyincorporated by reference.

TECHNICAL FIELD

The present disclosure relates generally toward computer systems,methods and tools of a user-guided medical network.

BACKGROUND

In the United States, medical care costs are often very high andunpredictable. The costs for a particular treatment or procedure mayvary wildly depending on numerous factors surrounding the patient,treatment location, doctors and insurers. Even with insurance coverage,medical consumers are often shocked with the costs presented in the formof soaring medical bills, expensive deductibles, donut-hole coveragesand high out of pocket maximums. Moreover, estimating the costs formedical procedures from the initial starting point to the conclusion ofthe treatment can be very difficult obtain before committing to aparticular course of medical care.

Several reasons can be attributed to why medical costs are unpredictableand thus making estimating or comparing medical costs difficult toachieve. First, unlike other products and services where cost estimatesare typically provided in advance, costs for medical procedures,services, facilities and supplies are largely unknown. Medicalproviders, such as hospitals do not make pricing information availableor publish prices in an easily accessible location. Moreover, not onlyare the costs of individual actions (identified by medical codes)largely unknown to medical consumers, but the actual medical codes usedfor the treatment of the medical consumer may not even be determined bythe insurance or medical provider until the procedures and services areperformed. Furthermore, medical providers of the treatment may not beknown to the medical consumer prior to the services being provided. Forexample, treatment options may change or additional personnel may beutilized such as an anesthesiologist or emergency room doctors.Moreover, additional costs may be added on afterward or adjusted basedon the progress of the patient. For instance, follow up visits,supplies, services and secondary procedures.

SUMMARY

A first embodiment of the present disclosure provides a method forsharing medical costs to a medical network comprising the steps of:accessing, by a computer system, a portal to the medical network;inputting, by the computer system, a natural language commandinstructing an upload of an explanation of benefits (EOB) document tothe medical network; digitizing, by the computer system, the EOBdocument; converting, by the computer system, text displayed by the EOBdocument to machine encoded text; tagging, by the computer system,identifying properties of the EOB document; anonymizing, by the computersystem, confidential patient information provided within the EOBdocument; uploading, by the computer system, a tagged EOB document tothe medical network; and receiving, by the computer system, rewardpoints in exchanged for the tagged EOB document uploaded to the medicalnetwork.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a diagram of an embodiment of a cloud computingenvironment for sharing medical costs to a medical network.

FIG. 2 illustrates abstraction model layers of a cloud computingenvironment consistent with the embodiments of the present disclosure.

FIG. 3 depicts a block diagram of an embodiment of a system for sharingmedical costs to a medical network.

FIG. 4 illustrates an embodiment of an interface of a medical networkinputting a natural language command to share medical documents.

FIG. 5 illustrates an embodiment of an interface of a medical networkinputting a natural language command to redact a shared medicaldocument.

FIG. 6 illustrates an embodiment of an interface of a medical networkinputting a natural language command to search similar cases to theuser.

FIG. 7 illustrates an embodiment of an interface of a medical networkdisplaying prioritized search results of similar medical cases.

FIG. 8 illustrates an embodiment of an interface of a medical networkdisplaying a timeline for treatment of a similar medical case returnedby the prioritized search results of FIG. 7.

FIG. 9 illustrates an embodiment of an interface of a medical networkdisplaying an explanation of benefits (EOB) document of one entry of thetimeline of treatment of FIG. 8.

FIG. 10 depicts an embodiment of an algorithm for sharing medical coststo a medical network.

FIG. 11 depicts a block diagram of a computer system able to implementthe methods for sharing medical costs to a medical network, consistentwith the disclosure of the present application.

DETAILED DESCRIPTION

Although certain embodiments are shown and described in detail, itshould be understood that various changes and modifications may be madewithout departing from the scope of the appended claims. The scope ofthe present disclosure will in no way be limited to the number ofconstituting components, the materials thereof, the shapes thereof, therelative arrangement thereof, etc., and are disclosed simply as anexample of embodiments of the present disclosure. A more completeunderstanding of the present embodiments and advantages thereof may beacquired by referring to the following description taken in conjunctionwith the accompanying drawings, in which like reference numbers indicatelike features.

As a preface to the detailed description, it should be noted that, asused in this specification and the appended claims, the singular forms“a”, “an” and “the” include plural referents, unless the context clearlydictates otherwise.

Overview

Existing tools and websites have been created to assist medicalconsumers with predicting cost estimates for medical treatment andservices. The existing tools often only provide a generic cost estimateor a “fair” market estimate of prices for individual procedures that amedical consumer may expect. Often, the existing tools and websites areinexact, resulting in the actual medical costs incurred by a customerthat can be quite significantly different from the cost estimateprovided by existing tools and websites.

Several challenges may still remain for medical consumers who attempt toestimate medical costs using the currently available systems, tools,methods and websites for estimating medical costs. First, the currentlyavailable resources may not link together individual billings and EOBs,making calculations of total costs for a treatment from beginning to endexceptionally difficult identify. A full picture of the total treatmentcosts may not be readily available. Second, existing tools and otherresources may make cost comparisons and estimations difficult forcomparing actual costs against the estimated “fair” costs for treating aparticular medical condition. Third, existing tools and systems forestimating costs may not provide any context behind a rating associatedwith actual medical treatments received by medical consumers. Forexample, existing estimation resources are unable to identifyextenuating circumstances, reasons for selecting a particular provider,occurrence of a second opinion or referrals. Moreover, due to particularlaws such as HIPPA, it can be difficult to obtain EOBs and medical billsthat are anonymous. The medical documents may be difficult to provide ormay be restricted, unless provided by the actual patient. Furthermore,existing estimation resources may be limited to by available informationor restricted to a particular nearby location and thus may not reveal adesirable service provider in a neighboring location or sort resultsaccording to cost, reputation, acceptable insurances or other specificdetails.

Embodiments of the present disclosure implement systems, methods andtools for sharing medical costs between prospective patients(participants seeking treatment) and existing patients (medical dataproviders) participating as part of the medical network. As part of themedical cost sharing program, prospective patients may actively querymedical costs and EOBs for specific conditions and treatments for thespecific conditions previously experienced by existing patients. Theexisting patients participating and contributing to the documentsaccessible by the medical network may upload redacted versions of EOBs,medical bills and other medical documents to the medical network inexchange for points and rewards.

In some embodiments of the system, methods and tools for sharing medicalcosts, a prospective patient may access the medical network via aninterface accessible through a network portal. For instance, an internetaccessible web portal hosted by a web server accessed by a thin clientsuch as a web browser. The prospective patient may log into a useraccount via the website or login page and query existing treatment costsand documents stored by the medical network. The prospective patient maycommunicate and query the desired information using natural languageinputs, by talking through a microphone or using voice commands toinstruct a client computing system to search the medical network forrelevant treatment information. The prospective patient may use naturallanguage commands or other inputs to filter the query results bycondition, location, cost, quality of service, service provider,insurance provider, or any other parameter that may be detailed by themedical documents accessible through the medical network.

In some embodiments, the search results may be analyzed by a computingsystem, prioritized and presented to the prospective patient based onthe relevancy of the search result to the search criteria inputted bythe prospective patient during the natural language input command. ThePrioritized search results may include relevant patient information suchas age, condition, quality of service, cost of the service, locationrelative to the prospective patient, the doctor providing the service,insurance company and the coverage of the services paid for by theinsurance company. As part of the analysis performed, each of theresults may be attributed an overall score based on the relevancy to thesearch criteria provided by the prospective patient. The overall scoremay be attributed by one or more systems making up the medical network,analyzing the search criteria and queried results using data analyticsto assess the best balance of cost, service, location, cost, etc. inorder to predict the most desirable and accurate service providerestimate for the prospective patient.

In some embodiments of the systems, methods and tools for sharingmedical costs in a medical network, the prospective patient may accessredacted medical records that may be uploaded by existing patients inorder to determine an estimated cost for treatment from start tocompletion of the medical treatment. A prospective patient may accessone or more of the uploaded redacted medical records and/or view atimeline of medical treatments comprising one or more medical bills,EOBs or other medical documents. A prospective patient may, from theprospective patient's client device, load and display each of themedical bills or EOBs returned by the prospective patient's query of themedical network's database of existing patients' medical documents. Forexample, the prospective patient may view a series of redacted EOBsuploaded by an existing patient receiving service near the prospectivepatient location. The medical documents relating to treatment of anexisting patient's condition may be presented in a timeline, wherein theprospective patient viewing the timeline returned by the search queryand select one or more EOBs to view more specific details of one or moreparticular documents of the timeline.

In some embodiments, existing patients accessing the medical network mayseparately login to a user profile having access to the medical network.The existing patients may choose to upload the existing patient'smedical documents, including medical billings and EOBs. An existingpatient logged into the medical network from a client computing systemmay administer a natural language input into a microphone or other voicereceiving hardware and request to upload a document to the medicalnetwork. The existing patient may scan or digitize the medical documentbeing uploaded. For example, the existing patient may use scanninghardware or a camera system connected to the existing patient's clientcomputer system in order to create a digital copy of a paper document.Alternatively, if the medical document is already in a computer readableformat, the existing patent may transmit the computer readable copy ofthe medical document being submitted to the medical network.

Once uploaded to the medical network, the image of the existingpatient's document may be converted to machine encoded text. Forinstance a computer system receiving the uploaded document may implementoptical character recognition (OCR) software on the documents to convertthe images of text to machine encoded text that may be understood by thecomputer systems of the medical network. The different fields of theuploaded document may be further analyzed and tagged by the computersystems or client devices of the medical network. For instance, theuploaded documents may be tagged with identifiers for the fields ofdate, location, cost, wait time, service provider, patient age andinsurance provider and the service provided.

Existing patients may further issue additional commands via naturallanguage command inputs to redact portions of the uploaded documents. Inparticular, an existing patient may redact private information thatcould be used to identify the particular existing patient. For example,the existing patient may execute a natural language command to redactinformation on the tagged document, including the patient's name,address, phone number, social security number, credit card/paymentinformation, insurance claim id numbers, patient id numbers, or anyother additional information that may be considered private or improperfor other individuals to access.

System for Sharing Medical Costs

Referring to the drawings, FIGS. 1-9 illustrate a diagram of anembodiment of a system 100 for sharing medical costs throughout amedical network 150 of computer systems, consistent with the disclosuresof this application. Embodiments of system 100 may comprise specializedcomputer systems 101 a, 101 b, 101 c, 101 d (collectively referred to as“client devices 101”), 110 connected together through network 150.Client devices 101 may include computer systems such as smartphones,tablets, desktop computers, laptops, etc., accessing the medical network150 using wired or wireless network communications. The specializedcomputer systems 110 forming the network 150 may be referred to as nodes110 and may comprise system hardware 160 or virtualized hardware 170 asexemplified in the drawing of FIG. 2. For example, computer systemsforming the hardware backbone of the medical network 150 may includemainframes 161, RISC architecture based servers 162, servers 163, bladeservers 164, storage devices 165 and networking components 166. Thespecialized computer systems 101, 110 of the medical network 150 mayhave a specialized configuration of hardware, software or a combinationthereof as depicted in FIGS. 1-9 as network application server software167, database software 168, medical network module 303 and as describedthroughout the present disclosure. Embodiments of the computer systems101, 110 may comprise one or more elements of the generic computersystem 1100 of FIG. 11, described in detail below. The elements of thegeneric computer system 1100 may be integrated into each of thespecialized computer systems 101, 110 described herein.

Embodiments of the computer systems 101, 110 operating as specializedcomputer systems may include a processor 317, 1191, specialized hardwareor circuitry, chipsets and/or software loaded in the memory device 316,1194, 1195 of the computer system 101, 110. Each of the computer systems101, 110 connected to the medical network 150 may perform one or morefunctions, tasks or routines relating to creating, searching, storing,uploading, analyzing and accessing medical documents and EOBs availablethrough the medical network and interface thereof.

Embodiments of the specialized hardware and/or software integrated intothe computer systems 101, 110 of the medical network 150 may beintegrated into the computer systems 101, 110 as part of the medicalnetwork module 303, 331, 341. The medical network modules 303, 331, 341may include hardware components and software applications performingeach of the functions of the computer system 101, 110 including, but notlimited to the creating, searching, storing, uploading, analyzing andaccessing medical documents and EOBs available through the medicalnetwork 150. As used herein, the term “module” may refer to a hardwaremodule, software-based module or a module may be a combination ofhardware and software resources of the computer systems 101, 110 and/orresources remotely accessible to the computer system 101, 110 via themedical network 150.

The hardware and/or software components of the computer systems 101, 110of the medical network 150 may each include one or more sub modulesperforming one or more specific tasks of the computer systems 101, 110sharing medical costs between one another over the medical network 150.The sub modules actively performing the tasks of a particular computersystem 101, 110 may vary depending on the function of the computersystem 101, 110 while accessing the network 150. For example, in someembodiments, a computer system 110 of the network 150 may be ananalytics processing system 301 having a medical network module 303actively engaging in the use of one or more sub modules such as acharacter recognition module 307, cognitive processing module 309,notification engine 310, AI natural language processor 311, scoringengine 313, reporting engine 314 and a rewards engine 315.

Likewise, a client computer system 101 connected to the medical network150 may be a prospective patient client device 330 and/or an existingpatient client device 340. A “prospective patient” may refer to a personor user accessing that medical network 150 for the purpose of estimatingmedical costs. An “existing patient” may refer to a person or useraccessing the medical network 150 to upload or provide medical documentssuch as billings or EOBs to the medical network 150. A client device 101that is operating as a prospective patient client device 330 maycomprise a medical network module 330 having active sub modules of aguided search module 333 and a results drill down module 335. A clientdevice 101 operating as an existing patient client device 340 mayinclude as sub modules of the medical network module 341, an uploadmodule 343 and a context augmentation interface module 345.

Embodiments of system 100, may include a plurality of computer systems101, 110 connected and placed in communication with one another over acomputer network 150, including one or more computing nodes 110 andclient devices 101. Embodiments of the network 150 may be constructedusing wired or wireless connections between each hardware componentconnected to the network 150. As shown in the embodiment of a cloudcomputing network 100 of FIG. 1, each of the computer systems 101, 110may connect to the network 150 and communicate over the network 150, forexample using a network interface controller (NIC) 319 or other networkcommunication device. Embodiments of the NIC 319 may implementspecialized electronic circuitry allowing for communication using aspecific physical layer and a data link layer standard, such asEthernet, Fiber channel, Wi-Fi or Token Ring. The NIC 319 may furtherallow for a full network protocol stack, enabling communication overnetwork 150 to the group of computer systems 101, 110 or other computinghardware devices linked together through communication channels.

The network 150 may facilitate communication and resource sharing amongthe computer systems 101, 110 and additional hardware devices connectedto the network 150. An example of the medical network 150 may includecloud computing networks 100, however it should be understood thatalthough this disclosure includes a detailed description of a cloudcomputing network 150, implementation of the teachings recited hereinare not limited to a cloud computing environment. Rather, embodiments ofthe present disclosure are capable of being implemented in conjunctionwith any other type of computing environment now known or laterdeveloped. For instance, the medical network 150 may include a localarea network (LAN), home area network (HAN), wide area network (WAN),back bone networks (BBN), peer to peer networks (P2P), campus networks,enterprise networks, the Internet, and any other network known by aperson skilled in the art.

Cloud computing is a model of service delivery enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g., networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models. The characteristics of the cloud computingmodel may be described as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported, providing transparency for both theprovider and consumer of the utilized service.

The service models under a cloud computing environment may be describedas follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices 101, 330,340 through a thin client interface 405 such as a web browser 403 (e.g.,web-based e-mail). The consumer does not manage or control theunderlying cloud infrastructure including network, servers, operatingsystems, storage, or even individual application capabilities, with thepossible exception of limited user-specific application configurationsettings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

The deployment models of cloud computing environments may be describedas follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment may be service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure that includes anetwork of interconnected nodes 110.

Referring to the drawings, FIG. 1 is illustrative of a medical network150 operating as a cloud computing environment. As shown, the cloudcomputing environment may include one or more cloud computing nodes 110with which client computing devices 101 used by cloud consumers, suchas, for example, desktop computers 101 a, 101 d, laptop computers 101 b,and digital assistant (PDA), tablet computers or cellular telephone 101c may communicate. Computer system nodes 110 may communicate with oneanother and may be grouped (not shown) physically or virtually, in oneor more networks, such as Private, Community, Public, or Hybrid cloudsas described hereinabove, or a combination thereof, allowing for thecloud computing environment of the medical network 150 to offerinfrastructure, platforms and/or software as services for which a cloudconsumer does not need to maintain resources on a local computing device101. It is understood that the types of computing devices 101 shown inFIG. 1 are intended to be illustrative only and that nodes 110 and cloudcomputing environment can communicate with any type of computerizeddevice over any type of network and/or network addressable connection(e.g., using a web browser).

Referring now to FIG. 2, a set of functional abstraction layers providedby a cloud computing environment of the medical network 150 is shown. Itshould be understood in advance that the components, layers, andfunctions shown in FIG. 2 are intended to be illustrative only andembodiments of the invention are not limited thereto. As depicted, thefollowing layers and corresponding functions are provided:

Hardware and software layer 160 includes hardware and softwarecomponents. Examples of hardware components include: mainframes 161;RISC (Reduced Instruction Set Computer) architecture based servers 162;servers 163; blade servers 164; storage devices 165; and networkingcomponents 166. In some embodiments, software components may includenetwork application server software 167 and database software 168.

Virtualization layer 170 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers171; virtual storage 172; virtual networks 173, including virtualprivate networks; virtual applications and operating systems 174; andvirtual clients 175.

Embodiments of the management layer 180 may provide the functionsdescribed below. Resource provisioning 181 provides dynamic procurementof computing resources and other resources that are utilized to performtasks within the cloud computing environment. Metering and Pricing 182provide cost tracking as resources are utilized within the cloudcomputing environment, and billing or invoicing for consumption of theseresources. In one example, these resources may include applicationsoftware licenses. Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal 183 provides access to the cloud computing environment ofthe medical network 150 for consumers (i.e. prospective and existingpatients) and system administrators. Service level management 184provides cloud computing resource allocation and management such thatrequired service levels are met. Service Level Agreement (SLA) planningand fulfillment 185 provides pre-arrangement for, and procurement of,cloud computing resources for which a future requirement is anticipatedin accordance with an SLA.

Workloads layer 190 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: recordsmanagement 191; web page management 192; searching and resultsmanagement 193; data analytics processing 194; profile management 195;and natural language processing 196 of natural language input commands.

Referring to the drawings, FIG. 3 illustrates a diagram of an embodiment300 of system 100 for sharing medical costs participating members of amedical network 150. Embodiments of system 300 may comprise a pluralityof medical network 150 nodes 110 and client devices 101. For instance,as shown in FIG. 3, the system 300 may include an analytics processingsystem 301 and an operational data system 302, each acting as a node 110of the medical network 150, whereas the prospective patient clientdevice 330 and existing patient client device 340 may each act asseparate and/or independent client devices 101 connecting to the medicalnetwork 150 for the purpose of estimating medical costs or providingdocuments to the medical network 150 allowing for prospective patientsto estimate medical costs.

Embodiments of the analytics processing system 301 may be a computingsystem comprising hardware and software components as depicted inembodiment 300 and in some embodiments, may integrate one or morecomponents of a generic computer system 1100 described in detail below.Embodiments of the analytics processing system 301 may comprise aprocessor 317, memory device 316, an input/output (I/O) interface 318and one or more computer readable data storage devices 320 as understoodby individuals skilled in the art and in accordance with processors,memory devices, I/O interfaces and computer readable storage devicesthat may be part of a generic computing system 1100. Embodiments of theAnalytics processing system 301 may include a medical network module 303comprising specific hardware modules, software modules loaded into thememory device 316 and a combination of hardware and software.

Embodiments of the medical network module 303 may include a characterrecognition module 307. The character recognition module 307 may performthe function or task of recognizing printed or written text characterson images of medical documents uploaded to the medical network 150 byclient devices 101, 340. Embodiments of the character recognition modulemay apply optical character recognition (OCR) to medical documents suchas EOBs and billings provided to the medical network 150. The characterrecognition module 307 may perform the function of photo scanning eachcharacter of text, character-by-character, analyze the image of theuploaded document and translate the character images intomachine-encoded text, such as ASCII.

In some embodiments of OCR processing the scanned-in image or bitmap maybe analyzed by the character recognition module 307 for light and darkareas in order to identify each alphabetic character or numeric digitinputted into the medical document. When the character recognitionmodule recognizes a character in an uploaded document, the character maybe converted into an ASCII code. In some embodiments, the characterrecognition module 307 may comprise specialized circuit boards and chipsthat may be designed expressly for OCR which may speed up therecognition process.

Embodiments of the medical network module 303 of the analyticsprocessing system 301 may also comprise a cognitive processing engine309. The cognitive processing engine 309 may perform the task ofenabling prospective patients, and existing patients accessing themedical network 150, to interact with the medical network 150 as adialog driven interface 403. For example, FIGS. 4-9 depict an embodimentof a dialog driven interface 405 accessed via thin client 403. Theinterface 405 may be displayed on a display device 401 of the patient'sclient device 330, 340. The dialog driven interface 403 may presentsystem generated dialogue 410 a, 410 b (referred to generallyhereinafter as “system generated dialogue 410”). As part of the dialoguedriven interface 403, a patient accessing the medical network 150 mayreceive system generated dialogue 410 prompting a response from thepatient using a natural language input command 407 a, 407 b (referred tohereinafter generally as “natural language input command 407”). In someembodiments, a patient may respond to the system generated dialogue 410by inputting natural language inputs into a microphone or voice inputsystem. In alternative embodiments, a patient may interact with thesystem generated dialogue 410 by inputting written responses via akeyboard, virtual keyboard, touch screen or other input device that maybe connected to an I/O interface of the client device 330, 340.

The cognitive processing engine 309 may operate as a simulation of thehuman thought process in a computerized model. Embodiments of thecognitive processing engine 309 may involve self-learning systems thatmay use data mining, pattern recognition and natural language processingto mimic the way a human brain functions, draws conclusions andinferences. The cognitive processing engine 309 may be capable of actingas an automated system for solving problems and generating responseswithout human assistance.

Embodiments of the cognitive processing engine 309 may form ontologiesto formally name, organize and define the properties of the data beingreceived by the cognitive processing engine. For example, commoncomponents of an ontology formed by the cognitive processing engine 309may include individual objects, classes of objects, object attributes,relations between individual or classes of objects, function terms,restrictions, rules, axioms and events that may change attributes orrelations.

One example of a cognitive processing engine 309 may be IBM's Watsoncomputer system. Embodiments of the cognitive engine 309 may use machinelearning algorithms in order to continually acquire knowledge from thedata fed to the cognitive processing engine 309 which may be from miningdata information and interacting with patients through the dialog driveninterface 405. From the data provided to the cognitive processing engine309 and the natural language input commands 407, the cognitiveprocessing engine 309 may be able to derive the context of back andforth dialogue between the patient and the analytics processing system301. For example, a natural language input that includes the phrase“torn ACL” may be identified with the context of the patient sufferingan injury. The context may further provide the cognitive processingengine 309 with a particular set of requirements for performing a queryof similar cases for which the analytics processing system may compare(i.e. searching for torn ACL cases as a requirement of the search).

In some embodiments of the analytics processing system 301, thecognitive processing engine may further perform a sentiment analysis ofthe natural language input commands to more accurately derive contextualclues about the information being received from a patient. Sentimentanalysis may refer to analyzing natural language, text, computationallinguistics and biometrics in order to systematically identify, extract,quantify and study the affective state of the subjective informationbeing provided by the patient during the back and forth dialogs 407, 410using the interface 405. The sentiment analysis can determine theattitude or emotions of the patient or other user inputting the naturallanguage or text into the interface 405. Using the sentiment analysis,the cognitive processing engine 309 may classify the polarity of thespeech or text provided by the patient and determines whether thelanguage provided is positive, negative or neutral and whether there isan associated emotional state that may be derived, such as angry, sad,happy, etc.

Embodiments of the cognitive processing engine 309 may operate alongsidethe AI natural language processor 311 (referred to herein as “NLP 311”).The NLP 311 may perform the function of analyzing, understanding andgenerating languages that the patients or users of the dialog driveninterface 405 may use natural language to interact with the analyticsprocessing system 301 of the medical network 150. The NLP 311 may teachthe analytics processing system 301 to understand human speech andlanguage and thus formulate responses to the inputs provided by patientsin return.

In some embodiments, the NLP 311 may be programmed to understand contextand linguistic structures of human speech in order to better understandthe natural language input commands 407 provided to the analyticsprocessing system 301. The NLP 311 receiving natural language inputcommands 407 may analyze the text of the input command 407, and breakthe unstructured text into situational criteria, preferences of thepatient, location details and other contextual details. The NLP 311 mayuse machine learning or other artificial intelligence techniques toexamine and analyze patterns in the speech or written data provided bythe patients or data stored by the devices of the medical network 150 inorder to improve the NLP's 311 programming. Tasks that may be performedby the NLP 311 may include sentence segmentation, part-of-speechtagging, parsing of the speech inputs provided to the NLP 311, deepanalytics of data sets and named entity extraction.

The NLP 311 may receive natural language input commands 407 or writtencommands spoken by a patient or user and respond using human language ofthe input rather than programming code. For example, as shown in FIGS. 4and 6, the analytics processing system 301 may present system generateddialog 410 in a human language such as English, receive a response froma patient in the patient's natural language, process the context of thepatient's message and respond accordingly. For instance, as shown inFIG. 6, the analytics processing system 301 may display on the interface405 a welcoming message asking how the medical network 150 may help thepatient. The patient may provide a natural language input command 407 a,which may describe the patient's current condition, in this example, “Itore my ACL”. As shown in the example, the NLP 311 understands thecondition described by the patient and suggests showing the patientsimilar torn ACL cases for the purpose of estimating medical costs (asshown in FIG. 7). The NCL 311 may understand different prioritizationand results filtering requests made by a patient. As shown in FIG. 6, apatient provides a natural language input command 407 b requesting thesystem 301 to prioritize the torn ACL cases by quality, price, time andlocation. The NLP 311 receives the proposed natural language command 407b and presents the results shown in FIG. 7 by prioritizing the torn ACLcases using the parameters requested by the patient.

In some embodiments of the system 300, the medical network module 303 ofthe analytics processing system 301 may comprise a notification engine310. The notification engine 310 may perform the task and/or function ofdelivering messages to patients and participants of the system 300. Thenotification engine 310 may send communications relating to the activityof a particular patient or a participant's account. A patient orparticipant of the medical network may set preferences of thenotification engine 310 within the patient's profile 337, 347 which maygrant permission or identify the types of notifications that may beconsidered acceptable for transmission. Communications may betransmitted to the patient or patient's client device 330, 340 viaemail, short messaging service (SMS), push notifications or via a directmessaging service.

The notification engine 310 may alert or message a patient about theavailability or status of another patient or user accessing the medicalnetwork in some embodiments. In other embodiments, the notificationengine 310 may alert a patient's client device 330, 340 if the clientdevice 330, 340 is receiving a contact request from another patient oruser. The notification engine 310 may also transmit notifications to anexisting patient's client device 340 informing the existing patient thatone or more medical documents uploaded by the existing patient has beenreturned in a query performed by a prospective patient's client device330 and/or selected by a prospective patient during a query performed bya perspective patient accessing the medical network 150. In someembodiments, the notification engine 310 may further alert a particularpatient or user that a report generated by the reporting engine 314 hasbeen created or received.

In some embodiments of the analytics processing system 301, the system301 may include a scoring engine 313. The scoring engine 313 may performthe function of analyzing the search results returned from theprospective patient's query of the operational data system 302, theexisting patient store 321 and the record management store 325, analyzeeach of the fields within the tagged medical documents returned by thequery and compare the value of the fields with the search criteria inorder to generate a relevancy score 703 a, 703 b (referred hereinaftergenerally as “relevancy score 703”). The scoring engine may rate each ofthe evaluated medical documents returned from the query based on thecriteria of the search including the condition treated, the cost oftreatment, the patient's age, insurance carrier, quality of service, anddistance between the location of the prospective patient and the serviceprovider. The more closely each of the criteria of the search match thevalues of the fields entered into the medical records returned by thequery, the higher the relevancy score 703 assigned to the particularmedical document may be. The analytics processing system 301 mayprioritize the search results of the query by relevancy score 703 anddisplay to the prospective patient a prioritized list of the searchresults, wherein the search results are organized by relevancy score.

Using the illustrative example of FIG. 7, each of the medical documents701 a, 701 b of the query may have different amounts of criteriamatching the particular search criteria designated by the prospectivepatient and/or provided by the prospective patient's profile 337. Byleveraging the cognitive processing engine 309, the scoring engine 313may use the conclusions and inferences of the cognitive processingengine 309 to assign a score 703 to each search result, wherein thecloser the search criteria from the prospective patient is to theinformation provided in each entry 701 a, 701 b, the higher therelevancy score 703 that may be assigned to the entry 701 a, 701 b. Asseen in the example of FIG. 7, the first entry 701 a belonging toPatient 1 may be assigned a relevancy score 703 a of 0.95 whereas thesecond entry 701 b may be assigned a lower relevancy score 703 b of0.85. Conclusions may be drawn that the first entry 701 a is a morerelevant or desirable estimation of the medical costs incurred for theconditions searched by the prospective patient.

In this example, the relevancy scores 703 of each entry 701 a, 701 b mayvary depending on the search criteria and prospective patient. Whileboth entries are for treatments of a torn ACL, the cognitive processingengine 309 and the scoring engine 313 may determine which entry 701 a,701 b may be the most relevant. In this case, the possible reasons thatmay be considered a better match between the prospective patient andPatient 1 of the first entry 701 a, may be attributed to the loweroverall costs between the entries ($6000 vs $7000), the lower wait timeexperienced by Patient 1 using the particular service provider (1 mo. vs2 mo.), the close proximity of the service provider in the first entry701 a (<1 mi. vs. 2 miles) to the prospective patient and the percentageof insurance coverage experienced by the patient of each entry (100% vs.90%). When each of the variables of the entries 701 are analyzed andtaken into account, it can be see for the particular torn ACL example,the scoring engine may identify the first entry 701 a as a closerrepresentation of expected costs, a better deal, better quality, etc.and thus the scoring engine may assign a higher relevancy score 703 tothe first entry 701 a over the second entry 701 b. It should be notedthat the simplicity of the example in FIG. 7 is for illustrativepurposes only. An actual search query performed by a perspective patientmay yield much more than two results in some instances. The number ofresults may only be limited by the total number of entries stored by thesystem 300.

In some embodiments, a prospective patient may choose to weight specificcharacteristics of the search as more important to the patient and thusthe weighting of a particular field in each entry may affect theprioritization of the search results returned by the scoring engine 313to the prospective patient's client device 330. For example, aprospective patient may identify the quality of service, servicelocation and costs as being greater factors for prioritization of thesearch results. Accordingly, the scoring engine 313 in coordination withthe cognitive processing engine 309 may score each search result of thequery with a higher focus on the weighted fields selected by theprospective patient conducting the query. In another instance, aprospective patient may deem that costs and insurance coverage may bethe most important factors, thus skewing the relevancy scores of theresults toward medical documents where the service provider treated thecondition more cheaply and through the use of insurance.

The analytics processing system 301 in some embodiments may furthercomprise a reporting engine 314. The reporting engine 314 may includetools or software applications capable of extracting the data of thequeries and prepare one or more reports based on the queries received bythe analytics processing system. For example, the reporting engine 314may be a dashboard accessible by a user, patient or administrator of thesystem 300. Embodiments of the reporting engine 314 may be responsiblefor returning the prioritized search results generated by a queryperformed by a perspective patient. The reporting engine 314 may alsoprovide detailed statistics, log events of each query and generatereports about the overall use of the medical network 150 by each of theusers, patients and system administrators.

In some embodiments, the reporting engine 314 may access the data storedby the operational data system 302 to generate one or more reports. Thereporting engine 314 may analyze the data transmitted, received andstored by the operational data system 302, including data stored by theexisting patient store 321, prospective patient store 321 and the recordmanagement store 325. Based on the data of the operational data system302 analyzed by the reporting engine 314, the reporting engine 314 maycreate one or more reports describing the trends of the system 300. Thetrends described in the report may include those trends relating to therequirements of each query and the matching results generated by thereporting engine 314. For example, individual users may be able togenerate a report depicting the number of times other participants ofthe medical network have accessed a particular set of profileinformation, a specific set of medical documents, existing patients thathave uploaded the most medical documents, prospective patients that havemade the most queries and the number of times the medical network hasfacilitated contact between prospective and existing patients.

The reporting engine 314 may also identify and report the total numberof searching being performed by users of the medical network 150, theoverall availability of EOBs by location, statistics about the costs oftreatment of each particular condition as a function of location, therelative quality of treatment based on locations and the types ofservices available by location. Users and patients of the system 300 mayaccess and request these reports in order to receive and display thereports on a display device, such as the display device 401 of theprospective patient client device 330 or the existing patient clientdevice 340.

Embodiments of the system 300 may further include a reward engine 315.The reward engine 315 may perform the task of tracking, monitoring,updating, distributing and allocating incentives provided to existingpatients and other participants of the network 150 for uploading medicaldocuments to the medical network 150. Rewards 409 may be in the form ofpoints, perks, coupons, discounts, gifts, rebates etc. In the exemplaryembodiment presented in FIGS. 4-9, the rewards 409 are shown in the formof points, which may be used as a form of currency on the medicalnetwork 150 for purchasing goods and services or may be used as currencyto access medical documents stored by the operational data system 302.For example, conducting searches of the operational data system 302,viewing the results or viewing detailed EOBs may cost a specific numberof points to access in some embodiments. Participants of the network 150may thus upload their own medical documents in exchange for points totrade in for accessing the medical documents uploaded to the network 150by other participants.

The reward engine 315 may allocate points or other rewards 409 toexisting patients that upload medical documents to the medical network150 or whom participate in providing useful information to the medicalnetwork 150. Useful information may include feedback and ratings aboutservice providers and/or other patients (i.e. if the participant is aservice provider). The reward engine 315 may monitor the operationaldata system 302 for the occurrence of transactions, such as feedback oruploaded medical documents. The transactions may each be tagged with auser profile that participated in the transaction. The rewards engine315 may be search a set of programmable rules to determine whichtransactions should result in the allocation or deduction of points orother rewards and apply the allocation or deduction to the reward valuesof the profiles participating in the transaction. Moreover, in someembodiments, of the system 300, the rewards engine 314 may save or storerecords and the history of each transaction for auditing and reportingpurposes. In some instances, participants receiving or spending rewards409 may access the transaction records stored by the rewards engine 314.

Embodiments of the system 300 may further comprise an operation datastore 302. The operational data store may be a specialized computersystem and/or node 110 of the medical network 150 tasked withmaintaining and serving the data stored by the medical network 150 whichmay be provided by existing patients or accessed by prospectivepatients. In some embodiments, the operational data store may be aseparate node 110 or computer system from the analytics processingsystem 301. In alternative embodiments, the operational data store 302may be integrated into the analytics processing system 301. For example,the analytics processing system 301 may include each of the data stores321, 323, 325 as part of the data storage 320 accessible to theanalytics processing system 301.

Embodiments of the operational data system 302 may store a plurality ofdifferent types of data and in some embodiments may organize the datainto distinct data structures. Examples of the data structures mayinclude an existing patient store 321, a prospective patient store 323and a record management data store 325. In some embodiments, eachparticipant of the medical network 150 may have a separate physical orvirtual data store containing record information about each participant,whereas in alternative embodiments, groups a perspective and existingpatients may have information stored collectively in the prospectivepatient data store 323 or existing patient data store 321 respectively.

Embodiments of the existing patient data store 321 may perform thefunction or task of storing links to stored documents uploaded andmaintained by the record management data store which holds a copy ofeach medical document provided to the medical network 150. When amedical document is uploaded by an existing patient, a record of theuploaded document may be created in the existing patient data store 321.The record of the upload may include Meta data describing each of thefields of the uploaded document and further comprise a pointer directingthe record of the uploaded document to the storage location of theuploaded document within the data structure of the record managementdata store 325.

Embodiments of the existing patient data store 321 may further storespecific user settings for each existing patient profile 347, includingprivacy settings. The privacy settings may include permissions toreceive notifications, messages from other participating users of themedical network (such as prospective patients) and default settings forredacting uploaded medical documents provided to the medical network.For example, an existing patient may create a default setting toanonymize any uploaded medical documents by redacting the patient'sname, address, phone number, claim ID numbers, insurance ID numbers asshown in FIG. 9. Embodiment of the existing patient data store 321 mayalso store contact information provided by the existing patient profile347, reward status 409, preferences for receiving reports from thereporting engine 314, the frequency of reports received from thereporting engine 314 and any feedback or ratings provided by theexisting patient about service providers or other participants of themedical network 150.

Similar to the existing patient data store 321, the prospective patientdata store 323 may be a data structure capable of organizing, storingand maintaining data relating to the prospective patients accessing thedata network 150 from one or more prospective patient client devices330. The prospective patient data store 323 may collect and storerecords and transactions relating to the prospective patient's profile337. For example, the prospective patient data store 323 may saverecords of each prospective patient's current and previous queries ofthe medical data network, including queries of the record managementdata store 325. The prospective patient data store may maintain a log orhistory of each query performed by a perspective patient and theprospective patient may retrieve a record of the prospective patient'sprevious queries. In some embodiments, the prospective patient datastore 323 may store each prospective patient's notification preferences,including the types of notifications that may be sent to the prospectivepatient, email addresses, mobile phone numbers, social media contactsand direct messaging user names that may be granted permission toreceive notifications from the medical network 150.

Embodiments of the prospective patient data store 323 may furtherinclude records of each prospective patient profile's 337 default querypreferences. For example, a prospective patient may be able to set adefault location to query medical services as well as a default costtolerance and insurance policy. Moreover, in some embodiments, theprospective patient data store may further maintain default weightingsbetween different fields and variables that the prospective patient mayselect in order to weight the prioritized search results and relevancyscores 703 returned by a query conducted by the prospective patient.Also, similar to the data stored by the existing patient data store 321,the prospective patient data store 323 may also maintain a record ofeach prospective patient's reward status, reporting preferences and anyfeedback or ratings that may have been provided by the prospectivepatient toward an existing patient or service provider.

Embodiments of the operational data system 302 integrated into thesystem 300 may include a record management data system 325. The recordmanagement data store 325 may perform the task or function of storingeach medical document maintained by the medical network 150, includingall of the EOBs, medical bills, medical records and other medicaldocuments uploaded to the medical network 150 by existing patients.Entries of the medical documents maintained by the record managementdata store 325 may be formatted, organized and tagged, allowing forfaster searching and retrieval of the records when queried byprospective patient client devices 330 or the analytics processingsystem 301. The entries of the record management data store 325 may beaccessed, amended or updated as requested by either the nodes 110 or theclient devices 101 of the network 150.

The entries of the record management data store 325, may, upon requestby another node 110 or client device 101, be transmitted by the recordmanagement data store 325 to the requesting device or computer system,such as the analytics processing system 301 which may subject therecords to analysis by the cognitive processing engine 309 and thescoring engine 314, for the purpose of matching the records to thesearch criteria, identifying the most relevant records and applying arelevancy score 703 to each of the records that are displayed as part ofthe prioritized search results.

In some instances, the data records being managed by the recordmanagement data store 325, may be retrieved by the analytics processingsystem 301 for the purpose of performing a historical analysis of themedical records available on the medical network 150 in order togenerate one or more reports by the reporting engine 314. The analyticsprocessing system 301 may input data from the fields of each recordmaintained by the record management data store 325 and identify patternsand statistics relating to the data of the records then generate thereport as a function of the patterns and statistical analysis performed.Moreover, in addition to using the data stored by the record managementdata store 325 for the purpose of generating reports, the data mayfurther be analyzed by the cognitive processing engine 309 and/or the AInatural language processor 311 for the purpose of using machine learningto further improve the accuracy and intelligence of both of the engines309, 311.

Embodiments of the system 300 may include one or more client devices 101connecting to the medical network 150 in order to participate and accessthe features of the medical network 150 as described herein. Embodimentsof the client devices 101 may include one or more existing patientclient devices 340 which may be operated by existing patients whom maycontribute medical data to the record management system in the form ofEOBs, medical records and billings. Additional client devices 101connecting to the medical network 150 may also comprise one or moreprospective patient client devices 330. The prospective patients mayinclude users and participants of the medical network 150 that may beseeking to search for medical cost estimations and query the medicalnetwork in order to view the records stored by the record managementdata store 325. Although the prospective patient client device 330 andthe existing patient client device 340 are represented in FIG. 3 as twoseparate computing systems, in some embodiments, the prospective patientclient device 330 and the existing patient client device 340 may be thesame computer system, wherein the computer system is capable of changingoperating modes from a prospective patient to existing patient operatingmode and vice versa.

Referring to the drawings, FIG. 3 depicts a block diagram of anembodiment of an existing patient client device 340. The existingpatient client device 340 may be any computing system, such as thegeneric computer system 1100 described in detail below. In addition tothe generic computing elements such as the processor 1191, memorydevices 1194, 1195 input devices 1192 and output devices 1193, theexisting patient client device 340 may comprise a medical network module341. The medical network module 341 may be a hardware module or asoftware module comprising programming code loaded into a memory deviceof the existing patient client device 340. Embodiments of the medicalnetwork module 340 may include an upload module 343, contextaugmentation module 345 and an existing patient profile 347.

Embodiments of upload module of the medical network module 341 loadedonto the existing patient client device 340 may perform the task orfunction of transmitting preparing and transmitting each of the medicaldocuments selected by the existing patient to be uploaded to the medicalnetwork 150. For example, an existing patient seeking to upload aparticular EOB to the medical network may scan the EOB using one or moreinput devices placed in wired or wireless communication with theexisting patient client device 340. For instance, a camera system,recording device, scanning device or other input device capable ofcapturing the EOB as a digitized document and saving the digitizeddocument to a computer readable storage device of the existing patientclient device 340. The upload module 343 may load the digitized documentinto the memory of the existing patient client device 340 and transmitthe digitized document from the existing patient client device 340 tothe operation data system 302 for storage and/or the analyticsprocessing system 301 for character recognition, cognitive analysis andtagging.

In some embodiments, the existing patient client device 340 may identifythe context of each digitized document being uploaded to the medicalnetwork before transmitting the digitized document to one or more nodes110 of the medical network 150. In order to perform the contextualanalysis of each medical document selected for upload using the uploadmodule 343, the user or the existing patient client device may providecontext of the digitized document through the context augmentationinterface 345. The context augmentation interface 345 may allow for theexisting patient to apply additional metadata to the digitized documentin order to more accurately process or query the digitized medicaldocument in the future. For example, the context augmentation interface345 may allow for an existing patient or the client device 340 to addcontext to the document by tagging the document with specific key wordsor fields, categorization of the document and applying location datadescribing the location where the services may have been provided.

In some embodiments, the context augmentation interface 345 may allowfor the existing patient to amend the documents prior to being uploaded,creating an opportunity for the existing patient to add additional datathat may not be present on a medical document such as an EOB or medicalbill. For example, the existing patient may supplement the costs of thebill or EOB by adding estimated travel or lodging costs, an itemized andaggregated total costs for treating the injury or performing theprocedure described by the document, rating the quality of the serviceprovider, providing feedback and comments about the service provider,describing the outcome of the procedure and provide additionalinformation about the insurance carrier and/or policy that covered theprocedure. Once the additional context has been compiled onto thedigitized document, the context augmentation interface 345 may save thedocument along with the updated context and notes provided by theexisting patient. Subsequently, the copy of the amended digital documentmay be uploaded to the medical network and stored by the recordmanagement data store 325 and record of the uploaded document may becreated or modified within the existing patient data store 321 and/orthe existing patient profile 347.

Furthermore, the embodiment of the existing patient client device 340may include a patient profile 347 which may be loaded into a memorydevice of the client device 340. The existing patient profile may storecustomized data and setting for the existing patient, including thepatient's name, address, contact information, insurance provider,notification and contact preferences, reward status, upload history,default document privacy settings (i.e. default redaction of documentsand visibility of contact information), login name and passwordauthentication.

Referring to the drawings, FIG. 4 depicts an embodiment of an existingpatient client device 340 displaying a thin client interface 405 such asthrough a web browser 403 or another software application capable ofaccessing a portal of the medical network 150. An existing patientaccessing the medical network 150 using the client device 340 mayauthenticate the patient's right to access medical network 150 bylogging in to the existing patient profile 347. Upon logging in via theweb portal or application portal, the client interface 405 may displayvia the display device 401 of the client device 340, information storedby the existing patient profile 347, including the name of the existingpatient or user, and the reward point status 409 of the patient.

In some embodiments of the existing patient client device 340, theinterface 405 may actively engage the patient with system generateddialog 410 provided via the cognitive processing engine 310 and the AInatural language processor 311. As shown in the example of FIG. 4, thesystem generated dialog 410 may ask the patient how the system mayassist the patient. Patients may choose to engage the medical network150 by responding to the system generated dialog 410. For example, anexisting patient may make a natural language input command 407 byspeaking into a microphone or voice recording device connected to theclient device 340 in some embodiments. In alternative embodiments, theexisting patient may input a response using a keyboard or virtualkeyboard provided on the interface 405. As shown in the example of FIG.4, an existing patient may enter a command using a natural languageinput 407 indicating that the existing patient would like to share oneor more medical documents with the medical network 150.

The embodiment of FIG. 5 depicts an example of an EOB scanned by theexisting patient and displayed on the interface 405 of the existingpatient client device 340. From the interface, the existing patient mayadd context to the EOB through the context augmentation interface andapply privacy measures to the document being prepared for upload to themedical network 150. Context augmentation, tagging, categorization,location information, redactions and additional modifications to thescanned document 501 may made using natural language input commands 407directing the system 300 and more specifically the analytics processingsystem 301 to amend the scanned document 501.

For example, the scanned document may contain information that theexisting patient may want to redact 503 in order to anonymize theexisting patient so that confidentiality may be maintained. Descriptiveuser information may be present in various categories includinginsurance information 507 and care provider information 509. Items suchas the name of the primary holder of the insurance, patient IDs, claimnumbers patient names, addresses and phone numbers may be desirable toredact. As shown in FIG. 5, the existing patient may input naturallanguage commands to redact 503 sensitive user information or mayinstruct the system 300 to apply default privacy settings prior touploading the scanned document 501. Once the anonymization has beenperformed by the existing patient, the existing patient may instruct theupload module 343 to transmit the scanned document 501 to one or morenodes 110 connected to the medical network. Subsequently, as a functionof uploading the scanned document 501, the existing patient's profile347 may receive a reward from reward engine 315 for participating in themedical network 150 by helping to build the record management data store325.

In some embodiments of system 300, one or more of the client devices 101may be a prospective patient client device 330. Each prospective patientclient device 330 may be any computing system, such as the genericcomputer system 1100 described in detail below. In addition to thegeneric computing elements such as the processor 1191, memory devices1194, 1195 input devices 1192 and output devices 1193. The prospectivepatient client device 330 may comprise a medical network module 330. Themedical network module 330 may be a hardware module or a software modulecomprising programming code loaded into a memory device of the existingpatient client device 330. Embodiments of the medical network module 330may include a guided search module 333, a results drill down module 335and a prospective patient profile 337.

Embodiments of the guided search module 333 may perform the function ortask of facilitating free form audio, speech and/or text input into theinterface 405 of the medical network 150. The guided search module 333may allow for the prospective patient to engage with the interface 405of the medical network using a free-form, interview style dialogapproach allowing for a back and forth of natural language inputcommands and responses with the cognitive processing engine 309. Theguided search module 333 may allow for the prospective patient operatingthe prospective patient client device 330 to naturally speak into amicrophone or other voice recording device to conduct a query of therecords stored by the medical network 150 and the operation data system302. Using natural language inputs, the prospective patient may definethe search criteria and one or more values that may populate the fieldsof the medical documents being retrieved. The prospective patient mayfurther use natural language to apply filters and/or weight variousfields that may be present in the retrieved medical records allowing forthe prioritized search results to be more customized to the specificsearch parameters authorized by the prospective patient. In alternativeembodiments, a prospective patient may also use the guided search module333 to input text into the interface 405 in order to communicate withthe medical network 150 and the nodes 110 of the network 150.

In some embodiments of the system 300, the prospective patient clientdevice 330 may further include a results drill down module 335 which mayperform the function or task of organizing the query results returned bythe analytics processing system by score, rank or prioritized matches.The results drill down module 335 may display the query resultsretrieved from the analytics processing system 301 and the operationaldata store 302 in a summarized format initially upon retrieval. However,a prospective patient may use the drill down module 335 to move deeperin the hierarchical structure of the search results to move on to moredetailed data by clicking through the returned results all the way downto the specific file that may have been uploaded by the existing user. Aprospective patient may drill down through the database of the recordmanagement data store and the search results to access information bystarting with a general category and moving through the hierarchy offield to file to record.

Embodiments of the medical network module 331 may further include aprospective patient profile 337 which may store the preferences,settings and search history of the prospective patient as theprospective patient operates the client device 330. A prospectivepatient may alter the settings of the profile and set defaults to theprofile 337 including acceptable systems for notifying the prospectivepatient, default query settings including specific search parameterssuch as cost, location, service provider, insurance carrier, etc. Theprospective patient profile 337 may also include the reward status ofthe prospective patient's account, participating history and a detailedsearch history of the prospective patient's account.

Referring back to the drawings, FIGS. 6-9 provide an example of aninterface 405 displayed by the prospective patient client device 330performing a search of the medical network 150 for medical costs beingshared by the medical network 150. As shown in FIG. 6, a prospectivepatient may access the interface 405 of the medical network via a thinclient 403 or other application capable of accessing the medical network150. The prospective patient may login to the prospective patient'sprofile 337. Once logged in, the interface 405 may generate systemdialog 410 a initiating the guided search performed by the guided searchmodule 333. The prospective patient may respond to the initial systemdialog 410 a by responding using natural language inputs such as naturalvoice dialog inputted using a voice recording system or microphone insome embodiments. In other embodiments, the prospective patient mayinput text directly into the interface using a keyboard, virtualkeyboard or other input device.

As shown in the exemplary embodiment of FIG. 6, a prospective patientmay respond to the initial system dialog 410 a with a natural languageinput 407 a describing the patient's condition. In this particularexample, the prospective patient describes the condition as a torn ACL,however, the prospective patient's condition could be any ailment orcondition that may require medical assistance by a medical professionalor medical service provider. The analytics processing system 301 maycontinue to respond and converse with the prospective patient throughthe interface 405. In the exemplary embodiment of FIG. 6, the analyticsprocessing system 301 and more specifically, the cognitive processingengine 309 and the AI natural language processor 311 may generate anappropriate response dialog 410 b. In this case prompting theprospective patient with a question of whether or not to query similarcases to the prospective patient's condition (the torn ACL).

In some embodiments of the system 300, the interface 405 may allow aprospective patient to further respond or refine the search criteriaproposed in the response dialog 410 b. As shown in FIG. 6, a prospectivepatient may describe additional search criteria with an additionalnatural language input 407 b. For example, a prospective patient mayprioritize certain fields of the query that are important to theprospective patient such as quality of service, price, wait time, andlocation of the available services.

In response to the search query proposed by the patient in FIG. 6 usingnatural language inputs, the analytics processing system may query theoperational data system 302 and the record management data store 325 forthe condition specified by the prospective patient. IN the particularexample of FIG. 6, the analytics processing system 301 may search therecord management system 325 for applicable torn ACL cases uploaded tothe operational data system 302, analyze each of the records containingthe queried condition and prioritize and additional parameters asrequested by the prospective patient's natural language input command407. In FIG. 7, an example of a prioritized search result is displayedby the display 401 of the prospective patient's client device 330.

As shown in FIG. 7, the prioritized search results may return aplurality of search results 701 a, 701 b which may be relevant to thesearch criteria of the prospective patient's query. Each of the returnedresults 701 a, 701 b may comprise a relevance score 703 a, 703 bdescribing how close to the query parameters each search result 701 a,701 b has been determined to be by the cognitive processing engine 309of the analytics processing system 301. The prioritized search resultsmay be presented to the prospective patient with the most relevantresult 701 a first and decreasing the relevancy and the list of resultsdescend. As shown in FIG. 7, the first result 701 a contains the highestrelevancy score 703 a of 0.95 and is therefore presented above the nextmost relevant search result 701 b, having a lower relevancy score 703 bof 0.85.

Additional features displayed by the prioritized search results mayinclude an option to contact 707 an existing patient linked to thesearch result or a service provider responsible for providing theservices described by a particular search result 701 a, 701 b. Moreover,in some embodiments, a satisfactory search result may not be identifiedby the prospective patient based on the search criteria of the query. Aprospective patient may modify or change the criteria of the query byinputting new or amended parameters, by either inserting text or via anatural language input command 407. As shown in FIG. 7, a prospectivepatient inputs a new command to expand the query by expanding thelocation of service providers beyond the scope of the immediate search,to neighboring locations.

In some embodiments, the prospective patient may drill down deeper intothe search results to obtain additional information via the resultsdrill down module 335. As shown in FIG. 7, a prospective patient mayaccess additional information from the search results, such as a link toa treatment timeline 705 of the existing patient that has provided themedical documents associated with the search result 701 selected by theprospective patient. A prospective patient may select the treatmenttimeline link 705 to drill down to the next level of information, asshown in FIG. 8. As shown in FIG. 8, the next level of the results drilldown may be a detailed treatment timeline 705 describing one or moreevents 801 in the course of treatment experienced by the existingpatient that shared the medical information. The treatment timeline 705may include a summary of each event 801, including the date, serviceprovided, the cost of each event 801 and an additional link to themedical document describing the event 801 of the timeline even further.In the particular example of FIG. 8, the treatment timeline 705 mayinclude links to the specific medical documents uploaded to the medicalnetwork. In the specific example, the treatment timeline includes aplurality of EOBs containing links to the document's scanned image. Inthe example provided by FIG. 8-9, EOB#1 803 may be selected and uponselection, may be displayed by the display 401 of the prospectivepatient's client device 330 as the results are drilled down even furtherto the specific record of EOB #1.

Method for Sharing Medical Costs

The drawing of FIG. 10 represents an embodiment 1000 of an algorithmthat may be implemented for sharing medical costs within a medicalnetwork 150, in accordance with the systems described in FIGS. 1-9 usingone or more computer systems defined generically in FIG. 11 below, andmore specifically by the specific embodiments depicted in FIGS. 1-9. Aperson skilled in the art should recognize that the steps of the methoddescribed in FIG. 10 may not require all of the steps disclosed hereinto be performed, nor does the algorithm of FIG. 10 necessarily requirethat all the steps be performed in the particular order presented.Variations of the method steps presented in FIG. 10 may be performed ina different order than presented by FIG. 10.

The algorithm 1000, described in FIG. 10, may initiate at step 1001 by auser or patient logging into the medical network 150 via a networkportal in order to access the medical network 150. Access to the medicalnetwork 150 may be obtained from a client device 101, 301, 302 loadingan application capable of connecting to the medical network or throughthe use of a thin client 403 such as a web browser. Once connected, thepatient may in step 1003 login to the patient's user profile 337, 347stored by the operational data system 302. A patient may login bypresenting access credentials to the network 150. For example, a patientmay login to the medical network using a login and password combinationtied to the specific profile 337, 347 of the patient.

In step 1005, the system 300 may determine whether or not the profile337, 347 has been previously registered to the patient. If the patienthas not previously registered and/or it is the first time the patient isaccessing the medical network 150, the algorithm may proceed to step1007 wherein the patient may register a new profile 337,347 with themedical network 150 before proceeding to step 1009. Otherwise, if thepatient is able to successfully log into a previously registeredprofile, the algorithm may proceed to step 1009.

In step 1009 of the algorithm 1000, a patient accessing the medicalnetwork 150 may input a natural language command 407 into the system300. The natural language command 407 may be entered using a microphoneor voice input device in some embodiments. In other embodiments, thenatural language command may be written using an input device such as akeyboard, virtual keyboard, touchscreen or other input device. Thenatural language input may be unprompted in some instances or may be inresponse to system generated dialog 410 displayed by the patients'client device 101, 330, 340. In response to the natural language input410, the system 100, 300 may provide a responding system generateddialog 410 or proceed with processing the natural language command 410.

In step 1011, the system 100, 300 may respond to the natural languagecommand 410 inputted by the patient in step 1009 by making adetermination as to the scope of the command. The algorithm 1000 may insome embodiments determine whether the natural language command isdirected toward querying the records maintained by the system 100, 300or contributing additional records to the system 100, 300 using theupload mechanism of an upload module 343. If, in step 1011, thepatient's natural language command 410 is directed toward querying therecords maintained by the system 100, 300, the algorithm may proceed tostep 1013. Conversely, if the natural language command 410 is directedtoward uploading or providing additional records to the system 100, 300the algorithm may proceed to step 1013.

In step 1013, the algorithm 1000 may query the record management datastore 325 of the operational data system 302, looking for records thatmatch or closely match the search criteria of the query. In step 1015,the system 100, 300 may search medical billings, EOBs and the details ofother medical records tagged with keywords and fields corresponding tothe requested search criteria. In step 1017, the analytics processingsystem 301 may compare each of the fields of the records retrieved fromthe record management data store 325 with the natural language inputsprovided by the patient. The analysis of the records retrieved may beperformed by the AI natural language processor 311, the cognitiveprocessing engine 309 and the scoring engine 313. Based on the analysisperformed by the analytics processing system 301, the scoring engine313, in step 1019 may assign a relevancy score 703 to each of therecords, EOBs and/or medical documents retrieved from the recordmanagement data store 325.

In step 1021 of the algorithm 1000, the analytics processing system 301may organize and present the search results of the query in step 1009 ina prioritized list which may be ordered according to the relevancyscores 703 assigned by the scoring engine 313. The prospective patientmay, in step 1023 view the prioritized search results displayed on aninterface 405 of the display 401 connected to the client device 330. Theclient device 330 may be directed by the prospective patient to drilldown further into the results using the result drill down module 335 inorder to obtain additional details of the search results. Theprospective patient may view summaries of the search results, drill downone level to a treatment timeline 705 displaying a summary of aplurality of events 801 occurring as part of the treatment timeline 705.In some embodiments, the prospective patient may drill down even furtherinto the search results and select individual EOBs 803 and display thedocuments scanned and uploaded by existing patients to the medicalnetwork 150.

Once the search results have been viewed in step 1023, a prospectivepatient may make an informed decision about the costs of treating aqueried condition as a function of viewing past treatment costs fromother patients that have treated the condition. In step 1025, theprospective patient may select a service provider associated with thetreatment from one or more of the search results returned from the queryin step 1021. The prospective patient may further proceed to contact andschedule an appointment to discuss or begin performing treatment of thecondition in step 1027. In some embodiments, the scheduling step may beperformed directly through the medical network 150. For example, aprospective patient may click a contact button 707 associated with theservice provider or obtain the service provider contact information. Insome embodiments, the service provider may be a member of the medicalnetwork 150 and may be directly messaged through the medical networkmessaging system.

Referring back to the determination step 1011, in some instances, thenatural language input 407 may direct the system 100, 300 to upload oneor more medical documents being provided by the existing patient of themedical network 150. The algorithm may proceed to step 1029, wherein theexisting patient may select one or more medical bills, EOBs or otherdocuments to be uploaded to the record management data store 325. Insome embodiments, the medical documents selected for upload may belocally stored on the existing patient client device 340, whereas inalternative embodiments, the medical documents being uploaded may beremotely stored in a network accessible data store remotely accessibleto client device 340.

In step 1031 of the algorithm 1000, the client device 340 may scan ordigitize the documents selected for upload in step 1029. The scanning ordigitization may be performed on hard copies of the documents beingselected for upload. The documents may be converted into a digitizedcopy using scanning hardware such as a scanner or preparing an image ofthe selected document using a camera system. The camera or scannersystem may be separate from the client device 340 or integrated into thehardware and/or software of the client device 340. Once scanned ordigitized, the system 100, 300 may convert the digitized documents tomachine encoded text in step 1033. Step 1033 may be performed via thecharacter recognition module 307 allowing for the system 100, 300 todecipher the letters and numbers on the printed image of the documentsand encode the image as machine readable text understood by thecognitive processing module 309 of the analytics processing system 301.

Once the text of the documents selected for uploading is placed into amachine readable text in step 1033, the algorithm may proceed to step1035 wherein the cognitive processing engine and/or AI natural languageprocessor 311 may tag identifying properties and fields of the documentsscheduled to be uploaded to the operational data system 302. Theanalytics processing system 301 may further amend the Meta data of thefile to include various keywords and descriptors of the file beinguploaded and/or the values associated with the uploaded files in orderto streamline and/or increase the query speed and accuracy of the system100, 300. In some embodiments, the algorithm 1000 may further amend thedocuments scheduled for uploading by providing additional context,ratings, feedback etc. via the context augmentation interface. Theadditional augmentations created by the existing user may also beincluded during the tagging process of step 1035.

In some embodiments of the algorithm 1000, the documents scheduled to beuploaded to the record management store 325 of the operational datasystem 302 may be anonymized in step 1037. Anonymizing the documents maybe performed as a default function in accordance with the privacysettings of the existing patient profile 347 or at the direction of theexisting patient providing the documents as a function of a naturallanguage input 407 instructing the system to redact sensitive oridentifying information. Once the sensitive information has beenredacted in accordance with the default privacy settings or at thedirection of the existing patient providing the medical documents, thealgorithm 1000 may proceed to step 1039. In step 1039, the uploadeddocuments that have been digitized and tagged may be stored by thesystem 100, 300 in the record management data store 325 and accessibleto prospective patients who may query the system 100, 300.

Lastly, once the upload of the documents to the record management datastore 325 has been completed in step 1039, the system 100, 300 may instep 1041 proceed to aware the existing patient uploading the taggeddocuments with rewards 409, such as points or other currency ordiscounts. The rewards 409 may be assigned by the rewards engine 315once the uploaded documents have been verified by the rewards engine 315as being saved to the record management data store 325.

Computer System

Referring to the drawings, FIG. 11 illustrates a block diagram of acomputer system 1100 that may be included in the systems of FIGS. 1-9and for implementing the methods for sharing medical costs with amedical network described in the algorithm of FIG. 10 and in accordancewith the embodiments described in the present disclosure. The computersystem 1100 may generally comprise a processor 1191, otherwise referredto as a central processing unit (CPU), an input device 1192 coupled tothe processor 1191, an output device 1193 coupled to the processor 1191,and memory devices 1194 and 1195 each coupled to the processor 1191. Theinput device 1192, output device 1193 and memory devices 1194, 1195 mayeach be coupled to the processor 1191 via a bus 1190. Processor 1191 mayperform computations and control the functions of computer 1100,including executing instructions included in the computer code 1197 fortools and programs for sharing medical costs with a medical network, inthe manner prescribed by the embodiments of the disclosure using thesystems of FIGS. 1-9 wherein the instructions of the computer code 1197may be executed by processor 1191 via memory device 1195. The computercode 1197 may include software or program instructions that mayimplement one or more algorithms for implementing the methods forsharing medical costs with a medical network, as described in detailabove and in FIG. 10. The processor 1191 executes the computer code1197. Processor 1191 may include a single processing unit, or may bedistributed across one or more processing units in one or more locations(e.g., on a client and server).

The memory device 1194 may include input data 1196. The input data 1196includes any inputs required by the computer code 1197, 1198. The outputdevice 1193 displays output from the computer code 1197, 1198. Either orboth memory devices 1194 and 1195 may be used as a computer usablestorage medium (or program storage device) having a computer readableprogram embodied therein and/or having other data stored therein,wherein the computer readable program comprises the computer code 1197,1198. Generally, a computer program product (or, alternatively, anarticle of manufacture) of the computer system 1100 may comprise saidcomputer usable storage medium (or said program storage device).

Memory devices 1194, 1195 include any known computer readable storagemedium, including those described in detail below. In one embodiment,cache memory elements of memory devices 1194, 1195 may provide temporarystorage of at least some program code (e.g., computer code 1197, 1198)in order to reduce the number of times code must be retrieved from bulkstorage while instructions of the computer code 1197, 1198 are executed.Moreover, similar to processor 1191, memory devices 1194, 1195 mayreside at a single physical location, including one or more types ofdata storage, or be distributed across a plurality of physical systemsin various forms. Further, memory devices 1194, 1195 can include datadistributed across, for example, a local area network (LAN) or a widearea network (WAN). Further, memory devices 1194, 1195 may include anoperating system (not shown) and may include other systems not shown inthe figures.

In some embodiments, rather than being stored and accessed from a harddrive, optical disc or other writeable, rewriteable, or removablehardware memory device 1194, 1195, stored computer program code 1198(e.g., including algorithms) may be stored on a static, non-removable,read-only storage medium such as a Read-Only Memory (ROM) device 1199,or may be accessed by processor 1191 directly from such a static,non-removable, read-only medium 1199. Similarly, in some embodiments,stored computer program code 1197 may be stored as computer-readablefirmware 1199, or may be accessed by processor 1191 directly from suchfirmware 1199, rather than from a more dynamic or removable hardwaredata-storage device 1195, such as a hard drive or optical disc.

In some embodiments, the computer system 1100 may further be coupled toan Input/output (I/O) interface (for example I/O interface 318) and acomputer data storage unit (for example a data store, data mart orrepository). An I/O interface may include any system for exchanginginformation to or from an input device 1192 or output device 1193. Theinput device 1192 may be, inter alia, a keyboard, joystick, trackball,touchpad, scanning device, bar code reader, mouse, sensors, beacons,RFID tags, microphones, recording device, biometric input device,camera, timer, etc. The output device 1193 may be, inter alia, aprinter, a plotter, a display device (such as a computer screen ormonitor), a magnetic tape, a removable hard disk, a floppy disk, etc.The memory devices 1194 and 1195 may be, inter alia, a hard disk, afloppy disk, a magnetic tape, an optical storage such as a compact disc(CD) or a digital video disc (DVD), a dynamic random access memory(DRAM), a read-only memory (ROM), etc. The bus 1190 may provide acommunication link between each of the components in computer 1100, andmay include any type of transmission link, including electrical,optical, wireless, etc.

The I/O interface may allow computer system 1100 to store information(e.g., data or program instructions such as program code 1197, 1198) onand retrieve the information from a computer data storage unit (notshown). Computer data storage units include any known computer-readablestorage medium, which is described below. In one embodiment, computerdata storage unit may be a non-volatile data storage device, such as amagnetic disk drive (i.e., hard disk drive) or an optical disc drive(e.g., a CD-ROM drive which receives a CD-ROM disk).

As will be appreciated by one skilled in the art, in a first embodiment,the present invention may be a method; in a second embodiment, thepresent invention may be a system; and in a third embodiment, thepresent invention may be a computer program product. Any of thecomponents of the embodiments of the present invention can be deployed,managed, serviced, etc. by a service provider able to deploy orintegrate computing infrastructure with respect to sharing medical costswith a medical network. Thus, an embodiment of the present inventiondiscloses a process for supporting computer infrastructure, where theprocess includes providing at least one support service for at least oneof integrating, hosting, maintaining and deploying computer-readablecode (e.g., program code 1197, 1198) in a computer system (e.g.,computer 1100) including one or more processor(s) 1191, wherein theprocessor(s) carry out instructions contained in the computer code 1197causing the computer system to share medical costs with a medicalnetwork. Another embodiment discloses a process for supporting computerinfrastructure, where the process includes integrating computer-readableprogram code into a computer system including a processor.

The step of integrating includes storing the program code in acomputer-readable storage device of the computer system through use ofthe processor. The program code, upon being executed by the processor,implements a method for sharing medical costs with a medical network asdescribed in this application. Thus the present invention discloses aprocess for supporting, deploying and/or integrating computerinfrastructure, integrating, hosting, maintaining, and deployingcomputer-readable code into the computer system 1100, wherein the codein combination with the computer system 1100 is capable of performing amethod of sharing medical costs with a medical network.

A computer program product of the present invention comprises one ormore computer readable hardware storage devices having computer readableprogram code stored therein, said program code containing instructionsexecutable by one or more processors of a computer system to implementthe methods of the present invention.

A computer program product of the present invention comprises one ormore computer readable hardware storage devices having computer readableprogram code stored therein, said program code containing instructionsexecutable by one or more processors of a computer system to implementthe methods of the present invention.

A computer system of the present invention comprises one or moreprocessors, one or more memories, and one or more computer readablehardware storage devices, said one or more hardware storage devicescontaining program code executable by the one or more processors via theone or more memories to implement the methods of the present invention.

The present invention may be a system, a method, and/or a computerprogram product at any possible technical detail level of integration.The computer program product may include a computer readable storagemedium (or media) having computer readable program instructions thereonfor causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

What is claimed:
 1. A method for sharing medical costs to a medicalnetwork comprising the steps of: accessing, by a computer system, aportal to the medical network; inputting, by the computer system, anatural language command instructing an upload of an explanation ofbenefits (EOB) document to the medical network; digitizing, by thecomputer system, the EOB document; converting, by the computer system,text displayed by the EOB document to machine encoded text; tagging, bythe computer system, identifying properties of the EOB document;anonymizing, by the computer system, confidential patient informationprovided within the EOB document; uploading, by the computer system, atagged EOB document to the medical network; and receiving, by thecomputer system, reward points in exchanged for the tagged EOB documentuploaded to the medical network.
 2. The method of claim 1, furthercomprising the steps of: inputting, by the computer system, a naturallanguage query command; searching, by the computer system, a data storeof the medical network for tagged documents uploaded to the medicalnetwork; prioritizing, by the computer system, results of the searchingstep as a function of a similarity to a patient's medical condition; andretrieving, by the computer system, a prioritized list of the taggeddocuments, the tagged documents including a descriptor of a serviceperformed and a price for performing the service performed.
 3. Themethod of claim 2, wherein the step of retrieving the results of thesearching step further comprises exchanging the reward points prior toviewing the prioritized list of tagged documents.
 4. The method of claim1, wherein the identifying properties of the EOB document tagged by thecomputer system are selected from the group consisting of a serviceprovided, condition treated, location, cost and service provider.
 5. Themethod of claim 1, wherein the step of anonymizing the EOB documentincludes inputting a second natural language command instructing thecomputer system to redact a selected portion of the EOB document.
 6. Themethod of claim 1, further comprising the step of storing the tagged EOBdocument to a data store of the medical network accessible to aplurality of members of the medical network, wherein the plurality ofmembers of the medical network can download, retrieve or view the EOBdocument uploaded to the medical network.
 7. The method of claim 2,wherein the prioritized list of tagged documents includes a link to atreatment timeline having a sorted list of a plurality of EOBs uploadedby a member of the medical network, wherein the sorted list is sorted bydate and includes a description of a treatment of a condition and costsfor treating the condition from a start of the treatment of thecondition to a conclusion of the treatment of the condition.
 8. Themethod of claim 1, further comprising providing at least one supportservice for at least one of creating, integrating, hosting, maintaining,and deploying computer-readable program code in a computer system, wherethe computer-readable program code in combination with the computersystem is configured to implement the steps of accessing, inputtingdigitizing, converting, tagging, anonymizing, uploading and receiving.